This invention relates to a method and system for managing resources for processing I/O requests from a host to a target device. The host has multiple adapters for transmitting the I/O requests to the target device. More specifically, the host assigns a number of I/O resources for issuing I/O requests to each adapter such that I/O requests are issued taking into account the number of I/O requests needed by each adapter and the number of I/O requests that can be processed by the system.
In a host server with a connection to a target device, input/output (I/O) requests are used to establish an I/O connection for transferring information with the target device. As would be readily understood by one of ordinary skill in the art, an I/O request is any software operation that transfers data to or from a processor, and an I/O connection is a path or route through which I/O requests are transferred. A host is one or more computer processors, and a target device is any device external to the host that is connected to the host such that information may be exchanged with an I/O request. Target devices may be any device that adds capacity to the host, such as a disk storage device, any array of disk drives, printers or similar devices.
An adapter, or alternatively, a host bus adapter, is a physical device that allows one hardware or electronic interface to be accommodated and transmitted without a loss of functionality to another hardware or electronic interface. As used herein, an adapter is a device that establishes an I/O connection for transferring I/O requests, by adapting and transmitting information that is exchanged between the host and the target device.
Target devices generally have only a limited number of I/O requests that may be active at any given time. When the target device is unable to process a new I/O request, it returns the unfinished I/O request to the host with a xe2x80x9cqueue fullxe2x80x9d status. When the host issues an I/O request, the target device either accepts the I/O request and an I/O connection is established, or the target device returns the I/O with a queue full status. The host must reissue the unfinished I/O requests. Target devices generally are able to return only a limited number of I/O requests with a xe2x80x9cqueue fullxe2x80x9d status. If this number is surpassed, the target device never receives the request and thus, never responds to it. This situation is especially problematic because if the target device does not respond to multiple requests, the host may treat the connection to the target device as a bad connection. If the host treats the connection to the target device as a bad connection, it stops sending any I/O requests to the target device through the connection. In such a case, the connection may need to be reestablished manually.
One method for ensuring that all I/O requests are processed is to reissue the I/O request returned with a queue full status. The I/O request may be reissued multiple times until the target device accepts it. If the host does not receive any response from the target device as in the case discussed above, the host is configured to wait for a period of time for a response before it reissues the I/O request.
However, issuing I/O requests requires processor resources, and thus, if I/O requests must be reissued repeatedly, the system encounters decreased performance. Therefore, it becomes desirable to decrease the number of times an I/O request is reissued before it is accepted by the target device. One current method for decreasing the number of times an I/O request must be issued is to delay for a period of time before reissuing an I/O request that has been returned with a queue full status. There is an increased chance that the target device may have completed enough I/O requests, and thus, may have the necessary resources to process a new I/O request.
A disadvantage of this method is that the delay is an imprecise estimate of the amount of time the target device will take to process enough I/O requests such that new I/O requests may be processed. If the target device is able to accept new requests at the end of the delay, it is possible that the I/O request could have been processed before the end of the delay. In other words, the delay as an estimate of the amount of time that the target device needs to process enough I/O requests such that new I/O requests may be processed was too long. If the target device is not able to accept new requests at the end of the delay, the I/O request must be reissued, thus using processor time unnecessarily and decreasing performance in the system.
Another method involves reissuing a single I/O request after a delay until the target device accepts it. No other I/O requests are issued until the target device accepts the designated I/O request. Thus, all I/O requests are held by the host as xe2x80x9cwaitingxe2x80x9d I/O requests until the designated I/O request is successfully accepted by the target device. Once the designated I/O request is accepted, all other waiting I/O requests are issued.
This method has one advantage of being able to use a shorter delay than the previously discussed method because only one I/O request will be issued repeatedly. Therefore, the I/O request does not have to compete with multiple I/O requests issued by the host. Because of the shorter delay, this method increases the precision with which the host determines that I/O requests may be sent to the target device.
One disadvantage of this method is that if a significant number of I/O requests are waiting on the host machine, the target device may be overwhelmed by I/O requests once the designated I/O request is accepted. This method does not provide for a way of monitoring the number of I/O requests that are issued simultaneously once the designated I/O request is accepted.
In order to minimize the number of I/O requests that are issued repeatedly, it is desirable in part to manage the I/O requests within the system such that the maximum number of I/O requests may be issued by the host with a minimal number of I/O requests returned by the target with a queue full status. These advantages and other advantages are provided by the system and method described herein, and numerous disadvantages of existing techniques are avoided.
In accordance with the system and method disclosed herein, a host manages and allocates I/O resources to issue I/O requests to a target device. By I/O resource is meant a software construct residing on the host that assigns the ability to issue a single I/O request. The host is configured such that it cannot issue an I/O request without an I/O resource, and each issued I/O request is associated with an I/O resource. As used herein, a used I/O resource is an I/O resource that has an issued I/O request associated therewith and an unused or available I/O resource is an I/O resource for which no I/O request has been issued.
A host is connected to the target device and has at least one adapter for sending I/O requests to the target device. Each I/O request is associated with one particular adapter. The host assigns a local resource to each adapter. By local resource is meant a variable number of I/O resources associated with each adapter.
As used herein, an I/O request that is sent from the host to the target device is called an issued I/O request. If there are no available I/O resources with which to issue an I/O request, then the I/O request remains unissued on the host and is called a waiting I/O request. Because I/O requests are associated with a particular adapter, the waiting I/O request are also associated with a particular adapter and thus, the waiting I/O requests must wait until the adapter with which they are associated has an available I/O resource.
In one aspect, a method involves sending I/O requests from a host to a target device. The host has at least one adapter for sending the I/O requests to the target device. If the target device cannot accept the I/O request, it returns a queue full status to the host, and the host sets the local resource associated with the adapter to the number of I/O resources currently being used by the adapter. The host then issues no more than the local resource""s number of requests at any given time for the adapter. The unissued requests are designated as waiting I/O requests that are issued once a resource becomes available.
In another aspect, in a system having two or more adapters, a method involves setting a local resource associated with each of the adapters to the number of I/O resources currently used by each adapter if the target device cannot accept an I/O request and returns a queue full status. The host will then issue no more than the local resource number of I/O requests associated with each adapter.
In yet another aspect of the invention, a method involves periodically rebalancing the local resources. By rebalancing the local resources is meant keeping the same or greater number of I/O resources in the system and reallocating the I/O resources between the local resources without receiving a queue full status. The rebalancing reflects changes within the system regarding the number of I/O resources needed with respect to the target device associated with each individual adapter. Preferably, the local resources are rebalanced if the local resource has not been adjusted within a threshold number of completed I/O requests. More preferably, the local resources are rebalanced if the local resource has not been adjusted within a threshold number of completed I/O requests, if the host has waiting I/O requests, and if the adapter has not been allocated a maximum number of I/O resources. As will be understood by one of ordinary skill in the art, adapters typically have a maximum capacity of I/O requests that may be issued. For example, a typical maximum capacity for an adapter may be 64 I/O requests, and therefore the maximum number of resources that should be allocated to such an adapter is 64. Therefore, the rebalancing will not occur if the maximum number of I/O resources have already been allocated to the local resource.
Preferably, the total number of I/O resources in the system is increased if there are more waiting I/O resources in the system than unused I/O resources. The increased number of I/O resources is then distributed to the local resources. More preferably, the total number of I/O resources in the system are distributed by increasing the local resource associated with each adapter that has waiting I/O requests associated therewith and decreasing the local resource associated with each adapter that has no waiting I/O requests associated therewith.
Most preferably, the total number of adjusted I/O resources in the system is the lesser of either the number of unused I/O resources in the system or the number of waiting I/O resources in the system. If the local resource associated with each adapter has waiting I/O requests associated therewith, the host increases the local resource by the total number of adjusted I/O resources in the system multiplied by the number of waiting I/O request associated with the adapter divided by the total number of waiting I/O requests in the system. If the local resource associated with each adapter does not have waiting I/O requests associated therewith, the host decreases the local resource by the total number of adjusted I/O resources in the system multiplied by the number of unused I/O request associated with the adapter divided by the total number of unused I/O requests in the system.
Preferably, the host rounds each increase or decrease to a local resource down to an integer number. The host then adds the fractional remainders from the increases to local resources to a first monitoring variable, and adds the fractional remainders from the decreases to local resources to a second monitoring variable. If either monitoring variable is equal to an I/O resource, the host adds one I/O resource to the local resource that it is currently adjusting.
In another aspect, the invention relates to a system for allocating I/O) resources. A host is connected to a target device. The host has at least one adapter for transmitting I/O requests to the target device. The host has one local resource associated with each of its adapters, and the local resources is assigned a variable number of I/O resources. The I/O resources are either used or unused I/O resources. The host is configured for issuing I/O requests if there is an available I/O resource and for retaining I/O requests as waiting requests if there are no available I/O resources. The host detects if the I/O request is accepted by the target device. The host has a first program routine for distributing the I/O resources if the target device does not accept the I/O request. The first program routine assigns a local resource to each adapter that is equal to the number of I/O requests issued by each adapter when an I/O request is returned with a queue full status. The host has a second program routine for allocating no more than the local resource number of I/O requests at a time to the each of the adapters.
By the terms xe2x80x9cprogram routinexe2x80x9d or xe2x80x9csubroutinexe2x80x9d is meant any block of code that may be logically grouped together and may or may not use the conventional subroutine interfaces as defined by typical programming languages. As would be understood by one of ordinary skill in the art, a program routine or subroutine is generally understood as a stylistic convention of programming, and thus different routines or subroutines may be written in multiple combinations and accomplish the same function. Thus, as used herein, a program routine or subroutine encompasses any block of code logically grouped together regardless of whether conventional subroutine interfaces as defined by typical programming languages are used.
Preferably, the host is configured to have a third program routine for periodically rebalance the local resources associated with the adapters. More preferably, the third program routine rebalances the local resources if the local resources have not been adjusted within a threshold number of completed I/O requests. Most preferably, the third program routine rebalances the local resources associated with the adapters if the local resources have not been adjusted within a threshold number of completed I/O requests, if the host has waiting I/O requests, if the adapter and if the adapter has not been allocated a maximum number of I/O resources.
Preferably, the threshold number of completed I/O requests is proportional to the total number of I/O resources in the system.
In another aspect, the third program routine has a first subroutine for increasing the total number of I/O resources in the system if there are more waiting I/O resources than unused I/O resources in the system, and a second subroutine for distributing the total number of I/O resources to the local resources.
In yet still another aspect, the second subroutine has a third subroutine for increasing the local resources for adapters that have waiting I/O requests associated therewith and for decreasing the local resources for adapters that do not have waiting I/O requests associated therewith.
Preferably, the third subroutine is programmed to determine the total number of adjusted I/O resources in the system. The total number of adjusted I/O resources in the system is the lesser of either the number of unused I/O resources in the system or the number of waiting I/O resources in the system. The third subroutine is programmed to increase the number of local resources for each adapter with waiting I/O requests by the total number of I/O resources in the system multiplied by a the number of waiting I/O requests associated with the local resource divided by the total number of waiting I/O requests in the system. The third subroutine is also programmed to decrease the number of local resources for each adapter without waiting I/O requests by the total number of I/O resources in the system multiplied by the number of unused I/O resources associated with the local resource divided by the total number of unused resources in the system.
Preferably, the third program subroutine is programmed to round the amount each local resource is increased down to an integer number and add the fractional remainder to a first monitoring variable. If the first monitoring variable is equal to or greater than an I/O resource, the host adds an I/O resource to the local resource being increased and subtracts the I/O resource from the first monitoring variable. The third program subroutine is also programmed to round the amount each local resource is decreased down to an integer number and add the fractional remainder to a second monitoring variable. If the second monitoring variable is equal to or greater than an I/O resource, the host adds one to the local resource being decreased and subtracts the I/O resource from the second monitoring variable.